Methods for determining cross-site scripting and related vulnerabilities in applications

ABSTRACT

The invention provides computer-implemented methods and computer systems for testing applications such as web-based (HTTP) applications for cross-site scripting (XSS) and related security vulnerabilities and permits the discovery of previously unknown XSS and related vulnerabilities in applications without relying on known or previously generated static XSS signatures. The invention may be applied to any type of XSS or related vulnerability for any variation of application code.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/658,393 filed Mar. 16, 2015, which claims the benefit of U.S.provisional application Ser. Nos. 62/126,412 filed Feb. 27, 2015,62/029,625 filed Jul. 28, 2014 and 61/953,775 filed Mar. 15, 2014, eachof which is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

The invention relates to the field of testing applications forcross-site scripting vulnerabilities.

BACKGROUND OF THE INVENTION

Currently, cross-site scripting (XSS) detection tools and programs thatcheck for XSS use signature (or “payload”) based methods to determine ifsuch vulnerabilities exist in the webpage of an application. What thismeans is that the tool will take a known signature/payload and use it todetermine if XSS exists. For example,

-   -   <scri-pt>alert(10)</scri-pt>        is a known test payload for XSS. Tools will append, replace or        comingle this signature/payload to the parameter of a URL or in        the GET/POST and as such:    -   h-t-t-p-://vulnsite.-com/vulnscript.php?vuln=<script>alert(10)</script>

If the signature/payload is returned, the website source is then runthrough additional tests to determine if the application is deemedvulnerable. The signature-based steps include:

Step 1: Find GET/POST URLs with parameters;

Step 2: Append, replace or comingle parameters with signatures/payloads;

Step 3: Make website request;

Step 4: Run source code through browser rendering (e.g., with theXenotix application) or analyze server response codes (e.g., with thewfuzz scanner) to determine if site is vulnerable; and

Step 5: Report Findings.

A good example of this signature based method is found in the OWASPXenotix XSS Exploit Framework. The Xenotix project claims “to have theworld's 2nd largest XSS Payloads of about 4800-plus distinctive XSSPayloads for effective XSS vulnerability detection.”

A second example comes from the security company Edge Security whichdevelops and maintains wfuzz, an open source scanner which includes XSSchecks. This tool also uses a signature/payload—they are calledInjections in wfuzz—based method of discovering XSS injections.

However, there is a fundamental drawback to these conventional methods,namely, if the exact string does not work (reflect) in the test, thetest will fail to detect the vulnerability in the web site even thoughthe vulnerability may, nevertheless, exist.

What is needed and provided by the present invention are new andimproved methods for testing applications for XSS vulnerabilities thatare neither based on nor limited by a compendium of XSS signaturepayloads.

SUMMARY OF THE INVENTION

One embodiment of the invention provides a computer-implemented methodfor testing an application, such as an interactive website, forcross-site scripting vulnerabilities that includes the steps of:

-   -   (a) for at least one field/parameter/URL of the application,        submitting a request in which the field/parameter/URL contains a        test slug consisting of one or more test characters, which may,        for example, include one or more encoded (such as URL-encoded)        or non-encoded (such as ASCII or HTML) special characters,        between two default slugs each consisting of non-special        characters;    -   (b) determining if the application returns (such as reflects)        the test slug with the test characters transformed or        non-transformed (e.g., encoded or non-encoded) in response to        the request;    -   (c) recording in tangible computer memory the result of the        determination made in step (b); and    -   (d) repeating steps (a)-(c) for a plurality of test slugs        including different test characters.        The method may be performed with all character sets, character        types and encoding types, for the test slug, without respect to        any pre-designation of a character as a special character.

The method may further include the steps of:

-   -   before steps (a)-(d), for at least one field/parameter/URL of        the application, submitting a request in which the        field/parameter/URL contains a default slug not having any        special characters; and    -   determining if the application returns (such as reflects) the        default slug in response to the request,    -   wherein if the application returns the default slug, the test        slug used in step (a) consists of the test character(s)        sandwiched between two strings of non-special characters the two        strings being the same or different.

The process may be iterated for each field/parameter/URL/etc. detectedin/provided by the application. URLs and parameters not previously knownmay but discovered in the testing process may be included in the testingand analysis. URLs and parameters may, for example, be generated by asoftware component, be discovered through implementing certainconditions such as forcing errors in an application, and/or may beimported from other applications. The method may culminate in the stepof preparing a report such as a spread sheet or document identifyingvulnerabilities detected by the method, which report may be stored in atangible computer memory of a computer system.

A related embodiment of the invention provides a computer systemconfigured to test an application for cross-site scripting and/orrelated vulnerabilities that includes:

-   -   at least one processor;    -   processor-accessible memory; and    -   processor-executable computer instructions stored in the        processor-accessible memory, said computer instructions        configured to direct the processor to perform the steps any of        the methods of the invention.

The computer system may further a network communication modules such asan Internet communication module under control of the at leastprocessor, for example for communicating over a network such as theInternet with remote applications that are being tested according to themethod(s) of the invention. For testing of “local” applications, acommunications module may not be required since the interaction betweenthe application being tested and the testing system may beimplemented/simulated within the same computer system.

Other objects and advantages of this invention will become apparent fromthe following description taken in conjunction with any accompanyingdrawings wherein are set forth, by way of illustration and example,certain embodiments of this invention. Any drawings contained hereinconstitute a part of this specification and include exemplaryembodiments of the present invention and illustrate various objects andfeatures thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates a manner in which default slugs and test slugs maybe employed according to the invention in a first scenario.

FIG. 1B exemplifies a modification of the results obtained in the firstscenario in which a submitted special character is not reflected but,instead, other characters are returned.

FIG. 2A illustrates a manner in which default slugs and test slugs maybe employed according to the invention in a second scenario.

FIG. 2B exemplifies a modification of the results obtained in the secondscenario in which two submitted special characters are not reflectedbut, instead, other characters are returned.

FIG. 3A illustrates a manner in which default slugs and test slugs maybe employed according to the invention in a third scenario.

FIG. 3B exemplifies a modification of the results obtained in the thirdscenario in which a submitted special character is not reflected but,instead, other characters are returned.

FIG. 4 shows sample processor-executable code (computer instructions,Python programming language) for generating a unique slug for each fieldfound in an application.

FIG. 5 shows a computer system embodiment of the invention configured totest remote target applications via a communications network.

FIG. 6 shows an exemplary report showing the parsing and exploitgeneration results obtained by the computer code presented in theComputer Program Listing Appendix.

DETAILED DESCRIPTION

The present invention provides new methods and systems for detecting XSSvulnerabilities including but not limited to reflected, in-memory,stored and DOM-based XSS vulnerabilities. Various embodiments of theinvention use character determination, source code context, source codeparsing, source code interpretation and character determination based onparsing and analyzing syntax (of HTML, XML, JSON, etc.) to determine ifan application is vulnerable rather than conventional testing withsignatures/payloads as in the above-described prior art methods. Themethods of the present invention may be employed across differenttechnologies—such as, but not limited to, ActiveX, Java, VBScript,Flash—to test where cross-site scripting attack vectors exist. Themethods of the present invention may be employed as an alternative toand/or in addition to prior methods for detecting XSS vulnerabilities.Also provided by the invention are methods for creating exploits basedon the results of the XSS vulnerability testing.

Various URLs and executable computer code are exemplified throughoutthis disclosure in explaining various aspects of the invention. In orderto comply with the regulations prohibiting presentation of active linksand executable computer code in patent specifications, the various URLsand code presented have been broken up in pertinent locations by theaddition of hyphens. Those skilled in the art will readily recognizethat the text so-modified refers to the corresponding unmodified text(without the hyphens).

Overview of Application Testing Methods

In order to find instances of XSS according to the invention, includingwithout limitation Stored XSS, the methods and system of the inventiontrack where the data goes into the application and where it comes out.This may be done by creating a unique slug (character string) for everyfield and submitting these slugs to the application. In one case theslug is an MD5 check sum but it could be any unique string identifyingthe field. If the application accepts the slug assigned to the field,the slug will either come out immediately (Reflected XSS), stay inmemory and be displayed on another page (InMemory XSS/ReflectedStoredXSS, hereafter referred to as InMemory) or stored in the database and besubsequently displayed either on the current page or a different page(Stored XSS), or in another process, such as email. It is also possiblefor the slug to be referenced in the DOM when returned (DOM XSS). It ispossible for all of these conditions to occur separately, at once or inany combination thereof.

A spider (spidering application), one example of a software component,is not necessary if one is testing a specific page. The more thoroughthe test is desired or necessary, the more spidering is necessary.Spidering is the gathering of links via HTML/AJAX/etc. and then callingeach link to see what data is returned. Entry points into theapplication (parameters of the application) may be found by spideringthe website (HTML/AJAX/Etc.) in addition to known possible entry pointssuch as HTTP headers including cookies or entry points discovereddynamically. In one method, fields may URL specific, not (global) byname. That is, the field “p” is a different parameter for the two URLsbelow:

-   -   h-t-t-p-://site.-com/1/?p=1 and h-t-t-p-://site.-com/2/?p=1

Spidering is just one technique that may be employed to obtain the urlsand parameters of an application. Obtaining (determining) these fieldsin an application may be also performed by other methods such as, butnot limited to, by using a piece of software known as a proxy in the artor “manually imported”, e.g., by inspection, selection and copying of aURL. The obtained URLs/field/parameters may be stored in tangibleprocessor-accessible memory in a data structure such as a database andretrieved as needed by a processor having access to the memory under thecontrol of computer instructions (stored in tangibleprocessor-accessible memory) that are configured to direct the processorto carry out the application testing method(s) and/or XSS testingmethod(s) of the invention. Spidering may be conducted as anunauthenticated, authenticated user or both. If spidering is conductedas two or more different authenticated users, it may be determined ifthe data submitted by one user is accessed by another user. Spideringmay be performed with different users (user profiles) with differentaccess levels, for example in a process of privilege escalation, therebytesting for attacks from one level of access against a different levelof access or against the same level of access. For example, in thismanner, it can be determined if an attack by a lower level user can berun against a user at a higher level and vice versa. If spidering isperformed, spidering at different times in the process may lead todifferent levels of validation for discovering data loading. Spideringmay be repeated at various points in the process of determining dataentry points since the data loaded may create new URLs to discover. Theslugs may then be submitted to those URLs (header, cookies, parameters,etc.), particular slugs being assigned to and submitted to theirrespective unique fields. The resulting output can be immediatelychecked (or later checked) for reflected values. Using the same session,one may spider again for slugs that may be in memory but not stored.Further, session information may then be cleared and spidering performedagain to find the slugs stored in the application. Any session orcombination thereof may be used to test for just Reflected or StoredXSS.

One or more or all of the following spidering methods may be used:

-   -   1. Spidering without authentication as same user (Reflected, DOM        & InMemory/Slugs);    -   2. Spidering with authentication as same user (Reflected, DOM,        InMemory & Stored Slugs); and    -   3. Spidering with authentication as more than 1 user (Reflected,        DOM, InMemory & Stored Slugs)        -   Spidering may be performed with one, two or more user            profiles at once. It is not restricted to one or two at a            time.

For spidering without authentication as same user (Reflected, DOM &InMemory Tokens), the method steps may, for example, include:

-   -   1. Spider web site to get URLs test;    -   2. Perform data tracing and check each page return (Reflected &        DOM); and    -   3. Re-spider to find submitted tokens (InMemory of server).        If the spidering examines reflected XSS or DOM-based XSS then a        session cookie (token) is optional but with if spidering        examines in-memory situations, the same-session token must be        used when spidering. (DOM refers to memory of the browser/client        computer, in-memory refers to memory, such as session variables,        and/or the way session data is handled by the server/target        application system for a given state.)

For spidering with authentication as same user (Reflected, DOM, InMemory& Stored Slugs), the method steps may, for example, include:

-   -   1. Authenticate and Save Cookie;    -   2. Spider web site to get URLs test;    -   3. Perform data tracing and check each page return (Reflected &        DOM);    -   4. Re-spider to find and save submitted slugs (InMemory);    -   5. Clear Cookies/Log out of application;    -   6. Re-Authenticate and Save Cookie; and    -   7. Re-Spider to find and save persistent/saved slugs (Stored).

For spidering with authentication as more than one user (Reflected, DOM,InMemory & Stored Slugs), the method steps may, for example, include:

-   -   1. Authenticate and Save Cookie for User 1;    -   2. Authenticate and Save Cookie for User 2;    -   3. Spider website to get URLs test as User 1;    -   4. Spider website to get URLs test as User 2;    -   5. Perform data tracing and check each page return as User 1        (Reflected & DOM);    -   6. Re-spider to find and save submitted slugs as User 1        (InMemory);    -   7. Re-spider to find and save submitted slugs as User 2        (InMemory);    -   8. Clear Cookies/Log out of application as User 1;    -   9. Clear Cookies/Log out of application as User 2;    -   10. Re-Authenticate and Save Cookie as User 1;    -   11. Re-Authenticate and Save Cookie as User 2;    -   12. Re-spider to find and save persistent/saved slugs as User 1        (Stored); and    -   13. Re-spider to find and save persistent/saved slugs as User 2        (Stored).

Various combinations of application parameters (URLs etc.) and theirassociated slugs may be generated by software components such as systemplug-ins for attempted loading into the application to be tested. Thegeneration of application parameters may include creating newcombinations of parameters and associated values that may not be foundby default on the website through techniques such as spidering. In onemethod, all application parameter loading techniques use the same slugfor the field. In another method, each loading technique uses a uniqueslug for that field and that load method. The latter variation will helptesting later on but is not a requirement. These processes are notfuzzing in the traditional sense. For example, in traditional fuzzing,it is usually the value of the parameter that changes in order to find avulnerability. By contrast, in this step of the invention, the focus ison loading data into the application, and tracing it, to find potentialXSS entry points. According to the present invention, one may change oneor many values or none at all—and different combinations of parametersthat differ in number and value from the originals may be used, forexample, in an automated process, in order to determine which data willbe accepted by the application and be reflected, in-memory, stored orreferenced in the DOM. For example, one may submit:

h-t-t-p-://site.-com/?parm1=[slug]&parm2=[slug]h-t-t-p-://site.-com/?parm1=[slug] h-t-t-p-://site.-com/?parm2=[slug]h-t-t-p-://site.-com/?parm1=[slug]&parm2=[blank]h-t-t-p-://site.-com/?parm1=[blank]&parm2=[slug]h-t-t-p-://site.-com/?parm1=[slug]&parm2=[original data]h-t-t-p-://site.-com/?parm1=[original data]&parm2=[slug]These variations are not considered fuzzing in the art. In addition, theapplication may alter the values of the parameters based on knownaccepted values in order to create conditions which trigger theapplication to accept the test slug or display XSS behavior. URLs may,for example, be generated, discovered or imported from otherapplications. New URLs that may not be discoverable by spidering may bediscoverable based on those tested, for example, by forcing an error tooccur in the application. URL data may, for example, also be obtainedfrom existing applications or user supplied data, such as zap, burp andURL lists.

A URL may or may not have parameters. Accordingly, slugs may also beplaced in the URL itself rather than or in addition to being assigned toa parameter. For example, a slug may be placed in a URL as shown below:

h-t-t-p-://vulnsite-.-com/[slug]/url1/h-t-t-p-://vulnsite-.-com/[slug]/url2/?parm=1234

Thus, default slugs may be loaded into a target application viaparameters/fields/URLs, etc. and incidences in which the default slughas been returned (reflected, stored in-memory, in DOM etc.) may bedetected and stored in the processor-accessible memory of the testingsystem including, for example, the context in which (where) the returneddefault slug occurs and the syntax in which it occurs, i.e., whatspecific characters surround the returned default slug. The computersystems and computer-implemented methods of the invention mayautomatically parse out and store in computer memory the context and/orsyntax information for the returned default slugs, for example, usingone of the following methods:

A first method including the following steps may be used:

-   -   1. HTML with returned default slug is found    -   2. The HTML and slug are used by the regex object/function to        determine which characters are needed to pass through the filter        to create executable HTML code (i.e., what is missing)    -   3. Regex is used to parse the HTML syntax and determine the        characters needed and the order. While different RegExs may be        used in this case it may be: matches=re.findall(‘<*?>’,        HTMLfull) where HTMLfull is a variable.    -   4. Finding/determining just the characters needed to be in front        of the exploit, all characters in the HTML (including characters        after exploit), and/or additional characters that may be added        or needed to create syntactically correct HTML (a putative        exploit).    -   5. (XSS Testing—see next section) The characters are then tested        by loading test slugs that present the test characters between        two default slugs.        Assuming the characters necessary to create executable code pass        through any filter and are returned, an exploit string can be        dynamically built. In this manner, the exploit string can be        built based on characters that pass through the filter, not        blindly. A person skilled in the art will recognize that using        RegEx is one method to select characters and other techniques        may also be used.

A second method, including the following steps may be used:

-   -   1. HTML with returned default slug is found    -   2. Context is used to determine which exploit to run    -   3. The HTML & slug and/or exploit are used by the regex        object/function to determine which characters are needed to pass        through the filter    -   4. Regex is used to parse the HTML syntax and determine the        characters needed and the order. While different RegExs may be        used in the case it's: matches=re.findall(‘<.*?>’, HTMLfull)        where HTMLfull is a variable.    -   5. Finding/determining just the characters needed to be in front        of the exploit, all characters in the HTML (including characters        after exploit), and/or additional characters that may be added        or needed by the exploit    -   6. (XSS Testing—see next section) The characters may then tested        by loading test slugs that present the test characters between        two default slugs.        Assuming the characters necessary to create executable code pass        through any filter and are returned, an exploit string can be        dynamically built. In this manner, the exploit string can be        built based on characters that pass through the filter, not        blindly. A person skilled in the art will recognize that using        RegEx is one method to select characters and other techniques        may also be used.

The Computer Program Listing Appendix presented at the end of thisdisclosure exemplifies computer code configured to parse out the syntax(such as special characters) surrounding a returned default slug anddetermine which characters may be added in order to build an executablepiece of code, i.e., an exploit. In the exemplified computer code,different algorithms are used to build different exploit strings. FIG. 6shows an exemplary report showing the parsing and exploit generationresults obtained by the program.

Overview of XSS Testing Method

Once all default slugs are mapped—where they entered and exit theapplication—one can then start testing to see which characters (or otherdata such as strings and exploits) pass through the application filter.The same method used to load the default slug into the application maybe used to test which different characters (and combinations thereof andsubsequently created exploits based thereon) can pass the application'sfilter. The method(s) and parameters used to load the slug into theapplication (in the application testing steps) may be stored in computeraccessible memory, for example, in a data structure, such as database,such as a relational database, so that a computer processor underdirection of computer instructions stored in tangiblecomputer-accessible memory can retrieve that data, modify it to createtests slugs that include additional characters such as specialcharacters and submit the modified slugs to the application beingtested. As explained in further detail below, the test slugs for afield/parameter may consist of the character(s) to be tested in themiddle of (sandwiched by) a first slug and a second slug, which slugswere found to be returned for the given field/parameter in theapplication testing phase. The first slug and second slug may beidentical or non-identical strings.

Since the test slugs created encompass unique strings, one can test notonly which specific characters pass the filter but also what strings ofcharacters pass the filter. This aspect of the invention is advantageousfor testing unique exploits for a particular piece ofbrowser-interpretable code such as HTML or a scripting language such asJavaScript, and VBscript or internal data structure such as for DocumentObject Model (DOM)-based XSS.

One method that may be used to test for slugs and exploits is to useXPATH to parse the HTML looking for the specific test slugs (uniquestrings). Other parsing methods, including known parsers and/or customdeveloped functions, may also be used for a given type of data or code,such as HTML, XML, JSON.

As the returned slugs are collected/discovered, the context of where theslug is returned (exists)—for example Script, Attribute, text, comments,etc.—is determined and recorded in memory This information may be usedto optimize the XSS testing since, at least in some cases, it can beused to minimize the number of characters or strings e.g., pieces ofcode such as HTML or scripting language—that need to tested instead oftesting all of them. In general, the context in which a returned slug isseen including, for example, as observed via parsing and analyzing itsoccurrence in syntax situations (of HTML, XML, JSON, etc.) may bedetermined and recorded in memory.

In one variation, the relevant pieces of code or data, such as HTML,XML, JavaScript, VBscript, JSON, DOM information etc., are recordedand/or saved, as the returned slugs are found, so that they can beprovided in a report and/or referred to later for example, in order tocreate and test exploits based on the information. Once it is determinedthe where the test slug occurs in the code or data, the part containingthe slug may be parsed to determine which characters pass through thefilter—for a given piece of the code or data. It is also possible thatunique strings—such as “script” or “<script”—will be rejected eventhough each character can pass through the filter, and thisdetermination may be made using the methods of the invention. Asdescribed in detail below, a method of building and testing unique XSSstrings may be applied in these situations.

Overview of Exploit Creation Methods

Once the characters and/or strings that pass through the filter of thetested application are determined using the XSS testing methods of theinvention, a determination of which exploits will work for theJavascript/Vbscript, piece of HTML, etc. may be made based on thatinformation.

As explained in further detail below, variations of different exploitsmay be created based on the results obtained from the XSS character andstring testing. The methods of the invention are able to generateexploits de novo without any guidance provided by knowledge of knownexploits. However, since the formats of many typical exploits are knownin the art, this information may also be used, in addition oralternatively, as a foundation for generating the exploits. In onevariation, this information can be stored/recorded ahead of time. Inanother variation, the exploit must be created dynamically based on thespecific way the application generates its output during the XSStesting. The XSS testing method provides information that is helpful forgenerating both exploit strings that are based on/resemble knownexploits and those that are not. While the method of the invention isable to (and may be used to) generate all exploits dynamically, it issometimes helpful to store and/or refer to known issues for optimizationpurposes. Once a working exploit is created through these methods, itmay be used in additional programs for testing and validation, which mayinclude methods such as but not limited to in and out of band callbacks,and processes such as but not limited to DOM abstraction. In addition,the code may be analyzed in an in-sandbox and/or out-of-sandbox manner.

Various aspects and embodiments of the invention are further describedherein below.

In one embodiment, the invention provides computer-implemented methodsand computer systems for testing a target application for cross-sitescripting and related vulnerabilities that includes any one ofcombination of or all of the following component methods or computersystem modules configured to perform the methods:

1. Determining fields/parameters/URLs of target application;

2. Slug assignment;

3. XSS testing methods;

4. Transformation/non-transformation determination; and

5. Exploit generation methods.

The methods of the invention may further include generating avulnerability report based on the results of the testing and thecomputer systems of the invention may further include a reportgeneration module for generating such a report which may be output onone or more output devices such as a display, a printer or an email, webor file server.

The following XSS test methods may be used according to the invention:

1. Brute force (testing every possible character/string between defaultslugs);

2. Character by context;

3. Character by context and tag (external Javascript); and

4. Character by parsing and analyzing HTML/XML/JSON/etc syntax

5. Character by context and syntax

The invention may also include charactertransformation/non-transformation determination steps. These methodsdetermine how the characters, strings or exploits are transformed by theapplication that is tested. For example, does the applicationtransform > to &gt.

In one embodiment, the invention includes the steps of:

-   -   1. Finding GET/POST URLs with parameters    -   2. Replacing parameters with a Default Slug value (such as the        regular character string 9b1e3f)    -   3. Making a website request (with the parameter replaced with        default slug 9b1e3f)    -   4. Examining the returned Source code to determine if Default        Slug was returned    -   5. If the default slug was not returned, the parameter is not        vulnerable to XSS    -   6. If the slug is returned, determining the context and/or        syntax of where the slug is returned, e.g., where and how in the        source code it occurs    -   7. From the context and/or syntax, determining the checks to be        performed.    -   8. Instead of checking signatures, testing if specific        characters (the “test characters”) such as special characters        are able to get though the web application filter for the        context where the slug is returned.    -   9. Padding the test character(s) such as XSS special characters,        between two default slug values (which could be already        generated), for example, 9b1e3f;9b1e3f , to create a “new        special character slug”.    -   10. Replacing the desired parameter to be tested with the new        special character slug.    -   11. Requesting webpages over and over with a new special        character slug test for each special character (or combination        thereof) to be tested. Sometimes, the test may be optimized or        streamlined by reducing the size of the set of special        characters (or combinations thereof) to be tested because        certain characters are only needed or relevant in certain        contexts but not others and/or syntax parsing reveals which        select characters need to be tested.    -   12. For each special character slug, examining the source to        determine if the entire slug is returned (such as 9b1e3f;9b1e3f)        ; if it is we know that we can get the special character (or        combination thereof) through the filter, otherwise the character        is filtered.    -   13. Based on the characters passed through the filter and the        context of the slug, determining if the website is vulnerable to        XSS or not and, importantly, characterizing the vulnerabilities        that may be present.

Further testing may be performed by parsing the source where theoriginal slug returned and determining the exact characters needed to bereturned by the test character-containing (such as specialcharacter-containing) slug. If all the characters needed are returnedfor a particular context/syntax it has been determined with nearcertainty that a vulnerability exists.

Since the method provides a determination of which characters are neededto write an exploit to take advantage of the vulnerability, additionalautomated tests may be conducted—such as filter testing with additionalslugged strings, automated signature/payload/injection/exploit writingand running the source code through browser rendering—to furtheraccurately determine the true risk that is present. Sandboxing, may, forexample, be used for validation.

The method looks for and characterizes reflected values—that is, slugdata that is submitted to an application and is returned back.Accordingly, in one implementation, the method may begin by firstdetermining if the application will return back data submitted to it(e.g., in a webpage) in the first place. If so, the location of wherethe data is returned in the webpage may be determined and recorded bythe application (for example, recorded in a data structure such as adatabase in the processor-accessible memory of the testing system). Inthis manner the context of reflected data is determined. Reflected datamay occur in multiple spots at the same time and different further testsmay need to be run for each context. From this context-based analysis,it is determined where the vulnerabilities may exist in the applicationand where to run tests specific to these contexts. Each context hasspecific characters which if returned constitute the core logicalcomponent of the vulnerability. For example, if the reflected data windsup in the context of JavaScript tags, the application may be vulnerableif specific characters are passed through the filter and are returned tous. Even within the context of the JavaScript tags, we may find thatcertain characters are needed but not others. These characters may bedifferent than those needed if the reflected data is returned in theHTML component of a webpage. In contrast to the present invention,signature-based methods are severely limited because they cannot accountfor each situation in view of the high degree of variation that ispossible. The methods of the present invention inquire into vastly more,if not all, possibilities and, therefore, are more accurate.Furthermore, once it is determined according to the methods of theinvention which characters will reflect (getting through a filter), theinvention may include further steps of dynamically building and testingfor all strings that will execute XSS and bypass the filter.

These context and/or syntax tests determine which special charactersreturned indicate a vulnerability. Specific analysis of the contextand/or HTML/XML/JSON/etc. syntax can determine which exact charactersare needed to be returned to make the site vulnerable to XSS. By testingwhich characters are returned, it is determined which pass through thefilter. If the application returns certain special characters submittedwithin a specific context and/or HTML/XML/JSON/etc. syntax, one willknow there is a vulnerability in the application. Using this method, itis not necessary to know ahead of time which signature to use becauseevery vulnerability instance can be uniquely tested to determine if aXSS vulnerability exists in the application.

Special characters may include those recognized in the art, such asthose shown in Table 1.

TABLE 1 Special URL- Encoded Known XSS Character Version Character NameCharacter? ~ %7E Tilde ! %21 Exclamation point @ %40 At sign # %23 Poundsign $ %24 Dollar sign % %25 Percent sign {circumflex over ( )} %5EExponential sign (hat) & %26 Ampersand Yes * %2A Asterisk ( %28 Openparenthesis ) %29 Closed parenthesis _(—) %5F Underscore + %2B Plus sign{grave over ( )} %91 Single quote − %2D Minus sign = %3D Equal sign [%5B Left bracket ] %5D Right bracket \ %5C Back slash { %7B Left brace }%7D Right brace | %7C Vertical Bar ; %3B Semicolon : %3A Colon ′ %27Single quotation mark Yes ” %22 Double quotation mark Yes , %2C Comma .%2E Period / %2F Forward slash Yes < %3C Less than sign Yes > %3EGreater than sign Yes ? %3F Question mark

The special characters indicated as known XSS characters in the tableare those most commonly needed for XSS but they are not necessarilyrequired. Different contexts and/or HTML/XML/JSON/etc. syntax for thetesting, such as different type of fields and parameters, may call fordifferent special characters or combinations thereof to be tested. Forexample, in a normal case, one might need three characters such as < >”whereas in another context one may need different characters such as “){ and }. Advantageously, the testing methods of the present inventionilluminate which characters are associated with and give rise tovulnerabilities without predicating the analysis on assumptions.

In one example of how the invention can provide particularizedinformation about vulnerabilities and application filters, there may becases in which <is reflected and > is reflected but <script> or <followed by any character is not reflected. The invention characterizesthese situations and further tests may be performed according toinvention to determine the additional filters at work.

Implementations with Encoded and Non-Encoded Characters

The method of the invention may also test the application beingevaluated for potential vulnerabilities to see if it automaticallyconverts submitted three character codes for special characters(“encoded characters”) into the special character so that the specialcharacters themselves (non-encoded) are reflected or the three charactercode is reflected. For example, in a process embodying this aspect, afirst step may include submitting as a field/parameter a string such asa default slug with encoded regular (non-special) characters only(%39%62%31%65%33%66) and determining whether what may be reflectedremains encoded or is converted to the non-encoded characters (9b1e3f).If is found that the application, such as server application, does notconvert encoded special characters, the remaining steps of the processcan proceed as described before by submitting padded slugs havingnon-encoded special characters and determining if and where they arereflected. On the other hand, if it is found that the application, suchas server application, does convert encoded special characters to returnthe corresponding non-encoded characters, the process may proceed bysubmitting padded slugs having the encoded characters (such as9b1e3f%279b1e3f in which %27 is the URL encoding for the non-encodedsingle quotation mark character), with or without also separatelysubmitting padded slugs having the non-encoded characters, and in eachcase determining if and where they are reflected. While the first stepwill help the application make decisions later on, it may beadvantageous to test characters and strings as both the encoded andnon-encoded independently of the first step.

Use of Unique Slugs for Each Field/Parameter/URL

In one variation of the invention, unique data slugs can be used to markwhere the data enters (which field/parameter) in the application andwhere it leaves the application (outputted HTML, JavaScript, etc.).Thus, a different unique slug may be used for each field/parameter in anapplication being tested for vulnerabilities according to the invention.These unique slugs may be strings that may be composed of characters(e.g., TESTSLUG), encoded data, hashes (e.g.,d8e8fca2dc0f896fd7cb4cb0031ba249) or numbers (e.g., 9876543210). Theslug may be any length that causes a unique pattern that may berecognized by the testing application. Examples of where the applicationcould store the slug could be in memory, defined data structure, on discor in a database. Thus, according to the invention, unique data slugsmay be used for each different field/parameter presented by anapplication so that reflection(s) resulting from particularfield/parameters can be traced and tracked and correctly attributed.This method, even employed alone without special characters (oneembodiment of the invention), provides very valuable information. Allfilters may be further tested up and down the stack—for example, theapplication filter and the database filter—for specific characters suchas the special characters, between two slugs. In this manner, thereturned slug behavior and XSS vulnerabilities associated with each dataentry point can be individually determined and a record made thereof.

It should be understood that the invention may be employed in variousdifferent contexts and situations in which data (including slugs) can be“reflected/outputted” directly or indirectly and immediately or in adelayed fashion and, thus, generally whenever data is submitted to anapplication and will be later outputted to another application (such asa web browser on a client device) either in modified or unmodified form.For example, the invention may be employed in relation to script tags,reference tags, direct html, DOM, CSS, stored data/ stored XSS,in-memory xss, etc. It may, for example, be employed with Stored XSS(a/k/a Persistent or Type I), with Reflected XSS (a/k/a Non-Persistentor Type II) and with DOM-based XSS (a/k/a Type-0). It may also beemployed in situations of InMemory XSS. Thus, for example, in onescenario, the methods and systems of the invention may be employed totest for vulnerabilities in a situation in which a web browser of a usermakes requests to a web server which immediately returns data to theuser's browser (and may not save any field/parameter data that may bereceived from the user (user device) and reflected back to the user).The methods and system of the invention may also be used to test whethermalicious code can be inserted from a first user's data when they usetheir web browser (or web-enabled application generally) to enter datato be saved in a database for later download by themselves or by otherweb users, such as in the case of updating profile data/fields on asocial network profile page of the user, such as a Facebook profilepage, which data is saved in a database by the social network to belater served to (downloaded by) users of the social network. The methodsand systems of the invention may be also employed to test situationswhere the data submitted is inputted into the application and returns ona different page then where submitted due to it being stored in thememory of the server for the session (InMemory XSS). The methods andsystems of invention may also be employed to test for DOM-based XSSvulnerabilities involving data that is not submitted to a server butremains in local/client/browser memory and is referenced in or by theDOM.

FIG. 1A illustrates the manner in which default and test slugs may beemployed in a first scenario, an HTML attribute tag, in which the hrefparameter of a link (note double quotation marks surrounding parameter)is first replaced by a default slug 9b1e3f (which passes, i.e., isreflected), then by a sequence of padded test slugs containing thenon-encoded special characters < >and / each of which passes (isreflected) in this example. From such a test, it is determined that theapplication is vulnerable with respect to the special characters < >and/ for the context of the first scenario. Finally, an example of“Attacker's Code” based on the test results and for which theapplication is susceptible is shown. FIG. 1B exemplifies a modificationof the results obtained in the first scenario in which a submittedspecial character > is not reflected but, instead, transformed intoother characters (the HTML multi-character code therefore) are returned.

FIG. 2A illustrates the manner in which default and test slugs may beemployed in a second scenario, an HTML attribute tag that includesmalformed HTML, i.e. single quotation marks surrounding the parameterrather than double quotes (as shown in FIG. 1A), in which the hrefparameter of a link is first replaced by a default slug 9b1e3f (whichpasses, i.e., is reflected), then by a sequence of padded test slugscontaining the non-encoded special characters < >and / each of whichpasses (is reflected) in this example. From such a test, it isdetermined that the application is vulnerable with respect to thespecial characters < > and / for the context of the first scenario.Finally, an example of “Attacker's Code” based on the test results andfor which the application is susceptible is shown. FIG. 2B exemplifies amodification of the results obtained in the second scenario in which twosubmitted special characters ‘ and > are not reflected but, instead,other characters (the HTML multi-character code therefor) are returned.

FIG. 3A illustrates the manner in which default and test slugs may beemployed in a third scenario, in the HTML body with the subjectparameter bounded by > and < and being first replaced by a default slug9b1e3f and then by a sequence of padded test slugs containing thenon-encoded special characters < >and / each of the padded test slugspassing (being reflected) in this example. Finally, an example of“Attacker's Code” based on the test results and for which theapplication is susceptible is shown. FIG. 3B exemplifies a modificationof the results obtained in the first scenario in which a submittedspecial character > is not reflected but, instead, other characters (theHTML multi-character code therefor) are returned.

EXAMPLES Generation, Assignment and Submission of Unique Slugs forDifferent Application Parameters/Fields

The following three slug assignment methods may, for example, be usedaccording to the invention:

-   -   1. one field;    -   2. algorithm-based (field same slug); and    -   3. algorithm-based (same field name different slug by URL).

One Field Slug Assignment

The generation, assignment and submission of unique slugs to each of anapplication's parameters/fields may be performed according to thefollowing seven step process, exemplified in the following examples:

-   -   Step 1: Get URL.    -   Step 2: Get URL parameters and values    -   Step 3: Save URL parameters and values    -   Step 4: For each parameter, generate md5checksum or modified        length md5checksum    -   Step 5: Assign the md5checksum or modified length md5checksum to        the parameter    -   Step 6: Save assignment    -   Step 7: Load slug into application through different/variety of        GET, POST, Cookie, HEADER methods (whatever entry point(s)        is/are applicable).

GET Method Example 1

Step 1: h-t-t-p-://192.168.56.103/testScripts/reflect.php?HTMLtext=HTML2ndtext&HTMLtext=HTMLtext&HTMLattDQ=HTMLattDQ&HTMLattSQ=HTMLattSQ&scriptattr=scriptattr&scripttag=scripttagSteps 2 and 3: HTMLtext=HTML2ndtext Step 4: 2f6b4e8 Steps 5 and 6:HTMLtext=2f6b4e8 Step 7: h-t-t-p-://192.168.56.103/testScripts/reflect.php?HTMLattDQ=2f6b4e8&HTMLattSQ=HTMLattSQ&HTMLtext=HTML2ndtext&scriptattr=scriptattr&scripttag=scripttag

GET Method Example 2

Step 1: h-t-t-p-://192.168.56.103/testScripts/reflect.php?HTMLtext=HTML2ndtext&HTMLtext=HTMLtext&HTMLattDQ=HTMLattDQ&HTMLattSQ=HTMLattSQ&scriptattr=scriptattr&scripttag=scripttagStep 2 and 3: HTMLattSQ=HTMLattSQ Step 4: 78752ef Steps 5 and 6:HTMLattSQ=78752ef Step 7: h-t-t-p-://192.168.56.103/testScripts/reflect.php?HTMLattSQ=78752ef&HTMLattDQ=HTMLattDQ&HTMLtext=HTML2ndtext&scriptattr=scriptattr&scripttag=scripttag

POST Method Example (Parameters are Parsed from HTML Form Tags)

Step 1: h-t-t-p-://192.168.56.103/testScripts/reflect.php Steps 2 and 3:HTMLattSQ=HTMLattSQ Step 4: 78752ef Steps 5 and 6: HTMLattSQ=78752efStep 7: h-t-t-p-://192.168.56.103/testScripts/reflect.php {u′post-data′:{u′HTMLattDQ′: u″, u′HTMLtext′: u″, u′scripttag′: u″, u′scriptattr′: u″,u′HTMLattSQ′: u′78752ef′}}

For the following original URL, examples are provided thereafter ofURL-tested (URL-slugged versions) generated and submitted.

Original URL: h-t-t-p-://192.168.56.103/testScripts/reflect.php?HTMLtext=HTML2ndtext&HTMLtext=HTMLtext&HTMLattDQ=HTMLattDQ&HTMLattSQ=HTMLattSQ&scriptattr=scriptattr&scripttag=scripttagURL Tested (URL-slugged) 1: h-t-t-p-://192.168.56.103/testScripts/reflect.php?HTMLattDQ=2f6b4e8&HTMLattSQ=HTMLattSQ&HTMLtext=HTML2ndtext&scriptattr=scriptattr&scripttag=scripttag URL Tested(URL-slugged) 2: h-t-t-p-://192.168.56.103/testScripts/reflect.php?HTMLattSQ=78752ef&HTMLattDQ=HTMLattDQ&HTMLtext=HTML2ndtext&scriptattr=scriptattr&scripttag=scripttag URL Tested(URL-slugged) 3: h-t-t-p-://192.168.56.103/testScripts/reflect.php?scriptattr=4a05a46&HTMLattDQ=HTMLattDQ&HTMLattSQ=HTMLattSQ&HTMLtext=HTML2ndtext&scripttag=scripttag URL Tested(URL-slugged) 4: h-t-t-p-://192.168.56.103/testScripts/reflect.php?scriptattr=4a05a46&HTMLattDQ=HTMLattDQ&HTMLattSQ=HTMLattSQ&HTMLtext=HTML2ndtext&scripttag=scripttag URL Tested(URL-slugged) 5: h-t-t-p-://192.168.56.103/testScripts/reflect.php?scripttag=eed97cd&HTMLattDQ=HTMLattDQ&HTMLattSQ=HTMLattSQ&HTMLtext=HTML2ndtext&scriptattr=scriptattr

The following example shows a URL that could be obtained by spidering,the associated POST URL and the data to submit to the POST URL.

... URL Spidered : h-t-t-p-://192.168.56.103/testScripts/reflect.php?HTMLtext=HTML2ndtext&HTMLtext=HTMLtext&HTMLattDQ=HTMLattDQ&HTMLattSQ=HTMLattSQ&scriptattr=scriptattr&scripttag=scripttag... URL POSTed (form method):h-t-t-p-://192.168.56.103/testScripts/reflect.php ... Data POSTed 1:{u′post-data′: {u′HTMLattDQ′: u″, u′HTMLtext′: u″, u′scripttag′: u″,u′scriptattr′: u″, u′HTMLattSQ′: u′78752ef′}} ... Data POSTed 2:{u′post-data′: {u′HTMLattDQ′: u″, u′HTMLtext′: u′26292b5′, u′scripttag′:u″, u′scriptattr′: u″, u′HTMLattSQ′: u″}} ... Data POSTed 3:{u′post-data′: {u′HTMLattDQ′: u″, u′HTMLtext′: u″, u′scripttag′: u″,u′scriptattr′: u′4a05a46′, u′HTMLattSQ′: u″}} ... Data POSTed 4:{u′post-data′: {u′HTMLattDQ′: u″, u′scripttag′: u′eed97cd′, u′HTMLtext′:u″, u′scriptattr′: u″, u′HTMLattSQ′: u″}} ... Data POSTed 5:{u′post-data′: {u′HTMLattDQ′: u′2f6b4e8′, u′HTMLtext′: u″, u′scripttag′:u″, u′scriptattr′: u″, u′HTMLattSQ′: u″}}

FIG. 4 shows exemplary notated computer code (JSON in Python programminglanguage) for the generation of a unique slug for each parameter/fieldof a URL. The code references a database in which all slugs are recordedand checks that there are no duplicates assigned (so that the slugassigned to each field/parameter in the application will be unique).

Algorithmic Slug Assignment (Field Same Slug)

The generation, assignment and submission of unique slugs to each of anapplication's parameters/fields may be performed according to thefollowing seven step process, exemplified in the following examples:

-   -   Step 1: Get URL.    -   Step 2: Get URL parameters and values    -   Step 3: Save URL parameters and values    -   Step 4: For each URL, generate the parameters to be submitted to        application by application of algorithm (single, tree,        alternating parameters, etc.)    -   Step 5: For each parameter, generate md5checksum or modified        length md5checksum    -   Step 6: Assign the md5checksum or modified length md5checksum to        the parameter    -   Step 7: Save assignment    -   Step 8: Load slug into application through different/variety of        GET, POST, Cookie, HEADER methods (whatever entry point(s)        is/are applicable).        The generation of the URL parameters and assignment of slug may,        for example, happen at the same time (e.g., steps 4, 5 and 6).

Algorithmic Slug Assignment (Same Field Name Different Slug by URL)

The generation, assignment and submission of unique slugs to each of anapplication's parameters/fields/URLs may be performed according to thefollowing seven step process, exemplified in the following examples:

-   -   Step 1: Get URL.    -   Step 2: Get URL parameters and values    -   Step 3: Save URL parameters and values    -   Step 4: For each URL, generate the parameters to be submitted to        application by algorithm (single, tree, alternating parameters,        etc.)    -   Step 5: For each different URL parameter variation, generate        md5checksum or modified length md5checksum even if field has the        same name    -   Step 6: Assign the md5checksum or modified length md5checksum to        the parameter    -   Step 7: Save assignment    -   Step 8: Load slug into application through different/variety of        GET, POST, Cookie, HEADER methods (whatever entry point(s)        is/are applicable).        The generation of the URL parameters and assignment of slug may        happen at the same time (e.g., steps 4, 5 and 6).

EXAMPLE Transform Compare Method

The following example illustrates the application of a method todetermine how the application transforms characters from one input intoa different output using a default slug 9876543210:

-   -   1. Sandwich character, string or payload, (e.g. <) between two        slugs (9876543210<9876543210)    -   2. Submit data to the application    -   3. Search for original submission (9876543210<987654321)    -   4. If not found search for slug: 9876543210    -   5. If slug found determine if there is a slug that soon follows        it    -   6. Parse/record/save entire character(s)/string between two        slugs    -   7. Alternatively, parse from start of one slug though the end of        the second capturing the slug-transformation-slug and then        remove the two slugs on both sides;    -   6. If so, note/record/save that the character transforms from <        into &gt (9876543210&gt;9876543210)

Generation of Exploits Based on XSS Testing Results

The results of the XSS testing of an application may be used to generateexploits for which the application is vulnerable. The slug may be usedto parse or interpret the HTML or Javascript/VBscript in order to createnew syntactically sound HMTL or JavaScript. Various methods such asXPATH may be used to do so. For example, where ‘A’ represents the slugvalue:

-   -   //*[@*[contains(.,‘A’)] or text( )contains[.,‘A2 )]]        RegEx may also be used. It is important to note that the slug        allows the application to break apart the code/data, such as        HTML, Javascript, VBscript, etc., so that its components can be        known. Once the components of the code/data are known, this        information can be used to write an exploit.

The order of steps in the methods of the invention can have someflexibility. In one method (not shown below), one can find the slug,determine the elements and test only for the characters needed to get anexploit to work. For example, under normal conditions, if one finds thestring <a href=“[slug]”> </a> we know that if a double quotation mark(“) does not pass through the filter (or is transformed into stringssuch as \” or &gt;) into the section of code that contains the slug, theexploit will fail. In this case, the HTML, script, etc may be analyzedfirst before the XSS test method is performed.

Whole Payload Method of Exploit Generation

A first method including the following steps may be used in thegeneration of an exploit and is exemplified with respect to HTML below:

-   -   Step 1: Find Slug (e.g., MD5 CheckSum or part thereof) in HTML;    -   Step 2: Use XSS Test Method to determine characters that pass        through filter;    -   Step 3: Check if exploit string passes through filter;    -   Step 4: Parse HTML to determine where Slug occurs;    -   Step 5: Use characters found to make syntactically correct HTML        and see if passes through filter; and    -   Step 6: Remove Slug and Save Exploit        -   Store Signature XSS String: <scri-pt>alert(‘xss’)</scri-pt>            in computer memory, and optionally a generate report            including the exploit.

Case 1 Example

md5sum = 5a105e8b9d40e1329780d62ea2265d8a Step 1: <ahref=“http://www.google.com”>5a105e8b9d40e1329780d62ea2265d8a</a> Step2: <a href=“h-t-t-p-://www.google.-com”>5a105e8b9d40e1329780d62ea2265d8a< 5a105e8b9d40e1329780d62ea2265d8a</a> <ahref=“h-t-t-p-://www.google.-com”>5a105e8b9d40e1329780d62ea2265d8a >5a105e8b9d40e1329780d62ea2265d8a</a> <ahref=“h-t-t-p-://www.google.-com”>5a105e8b9d40e1329780d62ea2265d8a /5a105e8b9d40e1329780d62ea2265d8a</a> <ahref=“h-t-t-p-://www.google.-com”>5a105e8b9d40e1329780d62ea2265d8a (5a105e8b9d40e1329780d62ea2265d8a</a> <ahref=“h-t-t-p-://www.google.-com”>5a105e8b9d40e1329780d62ea2265d8a ′5a105e8b9d40e1329780d62ea2265d8a</a> <ahref=“h-t-t-p://www.google.-com”>5a105e8b9d40e1329780d62ea2265d8a )5a105e8b9d40e1329780d62ea2265d8a</a> Step 3: <ahref=“h-t-t-p-://www.google.-com”>5a105e8b9d40e1329780d62ea2265d8a<script>alert(‘xss’)</script> 5a105e8b9d40e1329780d62ea2265d8a</a> Step4: (Part 1)<a href=“h-t-t-p-://www.google.-com”> (Part 2)</a> Step 5: <ahref=“h-t-t-p-://www.google.-com”>5a105e8b9d40e1329780d62ea2265d8a</a><scri- pt>alert(‘xss’)</scri-pt>5a105e8b9d40e1329780d62ea2265d8a<a></a> Step 6: <ahref=“h-t-t-p-://www.google.-com”></a><scri-pt>alert(‘xss’)</scri-pt><a></a>

Case 2 Example

md5 = ad0234829205b9033196ba818f7a872b Step 1: <ahref=“ad0234829205b9033196ba818f7a872b”>Link Text</a> Step 2: <ahref=“ad0234829205b9033196ba818f7a872b ″ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b <ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b >ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b /ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b (ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b )ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b ′ad0234829205b9033196ba818f7a872b”>Link Text</a> Step 3: <ahref=“ad0234829205b9033196ba818f7a872b <scri-pt>alert(‘xss’)</scri-pt>ad0234829205b9033196ba818f7a872b”>Link Text</a> Step 4: (part 1) <ahref=“ (part 2) ”>Link Text</a> // “></a><scri-pt>alert(‘xss’)</scri-pt> <a href=” Step 5: <ahref=“ad0234829205b9033196ba818f7a872b ”></a><scri-pt>alert(‘xss’)</scri-pt> <a href=“ad0234829205b9033196ba818f7a872b”>Link Text</a> Step 6: <a href=“”></a><scri-pt>alert(‘xss’)</scri-pt> <a href=“”>Link Text</a>

A variation of the first method including the following steps may alsobe used in the generation of an exploit and is exemplified with respectto HTML below:

-   -   Step 1: Find Slug in HTML    -   Step 2: Parse HTML to determine where CheckSum exists: syntax        check    -   Step 3: Determine characters needed to pass through filter based        on syntax of returned data (HTML/JSON/XML/etc.)    -   Step 4: Use XSS Test Method to determine characters that pass        through filter    -   Step 5: If characters pass through filter, build exploit string        based on characters and context and then check if exploit string        passes through filter    -   Step 6: (optional) Exploit string can be out of band callback        for extra validation    -   Step 7: Remove MD5 Check Sum and Save Exploit

Case 3 Example (Variation of First Exploit Generation Method)

md5 = ad0234829205b9033196ba818f7a872b Step 1: <ahref=“ad0234829205b9033196ba818f7a872b”>Link Text</a> Step 2: (part 1)<a href=“ (part 2) ”>Link Text</a> “></a><scri-pt>alert(‘xss’)</scri-pt> <a href=” Step 3: <ahref=“ad0234829205b9033196ba818f7a872b ″ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b <ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b >ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b /ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b (ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b )ad0234829205b9033196ba818f7a872b”>Link Text</a> <ahref=“ad0234829205b9033196ba818f7a872b ′ad0234829205b9033196ba818f7a872b”>Link Text</a> Step 4: <ahref=“ad0234829205b9033196ba818f7a872b <scri-pt>alert(‘xss’)</scri-pt>ad0234829205b9033196ba818f7a872b”>Link Text</a> Step 5: <ahref=“ad0234829205b9033196ba818f7a872b ”></a><scri-pt>alert(‘xss’)</scri-pt> <a href=“ad0234829205b9033196ba818f7a872b”>Link Text</a> Step 6: <a href=“”></a><scri-pt>alert(‘xss’)</scri-pt> <a href=“”>Link Text</a>

HTML/XML/JSON/etc Syntax Method of Exploit Generation

A method including the following steps may be used in the generation ofan exploit and is exemplified with respect to HTML below:

-   -   Step 1: Find Slug (e.g., MD5 CheckSum or part thereof) in        HTML/Script/JSON/XML/etc. and use context/syntax to determine        characters needed to test;    -   Step 2: Use XSS Test Method to determine characters that pass        through filter;    -   Step 3: Build custom exploit with syntactically correct        HTML/WL/JSON/etc based on characters that pass through filter        from XSS Test Method. Here, build/generate an exploit means the        application automatically determines the sequence of characters        needed to create syntactically correct code that will execute;    -   Step 4: Check if syntactically correct exploit string passes        through the target application's filter. The correctness of the        syntax can be checked, for example, by the call back method,        out-of-band method and/or in a sandbox method;    -   Step 5: If the exploit is determined to pass through the        application's filter, remove the default slug portion and save        the validated exploit. For example,    -   store Signature XSS String: <scri-pt>alert(‘xss’)</scri-pt> in        computer memory and optionally generate report including the        exploit(s).

Method for Discovering the Size/Maximum Size of a Field

There may be cases in which the size of the exploit or putative exploitmust be determined. This computer-implemented method allows the lengthof the field and or database field to be discovered so that the correctsize exploit may be determined and used. The method may include thefollowing steps:

1. Select/generate a unique long slug. (While this could be any lengthstring one would like to test; ideally it is at least the length of theexploit.);

2. Submit the long slug to application;

3. Check resulting output for the slug;

4. If not found, check remove one character from the unique long slugand check again;

5. Repeat checks until field is found; and

6. Determine difference in size between the slug found in applicationand one submitted to get length of field.

The determined field size may be used to optimize the exploit. Thismethod of determining field size may be used in addition to and/or inconjunction with any of the other embodiments of the invention andvariations thereof described herein. Some fields have a fixed length andsome do not have a fixed length. For those that are fixed, the lengthmay be determined. Once it is determined that there is a stored field(by seeing a single test slug reflect) then the size of the field can bedetermined in the process of character testing (one way). Another way todetermine field size is to start testing characters first after it hasbeen found that the default slug has reflected and then add charactersto it and resubmit it until an upper limit is reached, i.e., until thestring is no longer reflecting (not as complete but quicker than thefirst method).

FIG. 5 shows a network-connected computer system embodiment 501 of theinvention with various interacting target application computer systemsshown. Computer system 501 of the embodiment includes a processor 502(i.e., computer processor), processor-accessible memory 503,processor-executable computer instructions 504 stored in memory 503, atleast one input device 505 such as a keyboard or microphone operablyconnected to the processor, at least one output device 506 under controlof the processor such as a display or a printer, and a networkcommunications server 507 that permits data to be sent to and receivedfrom other computing devices and systems, for example, via the Internet,a cellular telephone network, a private data network and/or a directdata transfer connection. Memory 503 also includes one or more datastructures, such as one or more relational databases, for storing datautilized by and generated by the system in the course of its operation.Server 507 may also be considered an output device. The aforementionedcomponents of system 501 are collectively mutually configured to providethe following functional modules of the system as directed by theprocessor under control of the computer instructions:

-   -   (1) a Target Application Designation Module 508 which permits a        user of the system to input, for example via input device 505 a        target application, such as a web page for which XSS        vulnerability testing is desired. Target Application Designation        Module 508 may, for example, present a user interface such as a        secure web page with which the user can input the        designation(s);    -   (2) Field/Parameter/URL Determination Module 509 that        determines, for example, by spidering and/or by forcing errors,        what the fields, parameters and/or URLs are for the target        application. At least some of this information may already        exist, for example, in a compiled form and be uploaded or        otherwise entered and stored in memory 503;    -   (3) a Default Slug Generation, Loading and Detection Module 510        that generates a default slug which is a string of characters,        such as non-special characters, and submits (loads) the default        slug to the application via the fields/parameters/URLs etc. and        determines (detects) where, if at all, and how the default slug        is returned by the target application, i.e. a reflected slug,        stored slug, in-memory slug and/or DOM, etc. This module may        also be configured to detect and parse out the context and/or        syntax in/with which the returned slug appears, and store the        results in the memory;    -   (4) a Test Slug Generation and XSS Testing Module 511 that (i)        generates test slugs consisting of two default slugs which are        the same or different (that was/were determined by Module 510 to        be reflected by the target application) surrounding a test        character or test string of multiple test characters, such as        but not limited to a special character or a string of characters        including one or more or all special characters, (ii) submits        the generated test slugs in the target application fields,        parameters and/or URLs to the target application, (iii)        determines if and where the test slugs are returned and whether        any of the characters (which may or may not have passed through        a filter if the application has a filter) in the test string of        the test slug are transformed in the returned test slug or not,        and (iv) stores the results of the testing in memory 503. For a        given length or given lengths of the test slugs, Module 511 may        be configured to generate and submit all possible test slugs to        the target application.    -   (5) an Exploit Generation and Validation Module 512 configured        to (i) build/generate custom exploits with syntactically correct        HTML/XML/JSON/etc. based on characters that are returned by the        application (which may or may not have passed through a filter        if the application has a filter) from XSS Testing by Module        511, (ii) determine if syntactically correct (executable)        exploit string(s) passes through filter (the correctness of the        syntax can be checked, for example, by the call back method,        out-of-band method and/or in a sandbox method), and (iii) if a        validated exploit is determined, saving the exploit in memory        503; and    -   (6) a Report Generation Module 513 configured to generate and        output a vulnerability testing results report via output device        506 or electronically in a file via server 507 which report        includes, for example, an identification of any fields,        parameters, URLs in which a test slug submission resulted in a        reflection in which one or more test characters of the test slug        were transformed, and identification of the corresponding        character(s) and/or string of characters that experienced a        transformation, and a description of any exploit generated and        validated (for a field, parameter, URL, etc.) by Module 512.

As further shown in the FIG. 5, system 501 is operably connected fortwo-way communication to a communications network 520, such as theInternet, a cellular telephone network, a local area network, and/or aprivate communications network, via server 507. Target applications 531and 532 to be tested by system 501 are provided by computer systems thatare similarly operably connected for two-way communication to network520. For example, target applications 531 and 532 may be web pagesserved by remote web servers in the normal course of their operation andsystem 501 may interrogate the target applications via their regularcommunication network connection(s).

Advantageously, the methods of the invention may be directed to anentire target application, such as an entire web site, or to particularsub-applications such as login pages, shopping carts, forms, web pages,dynamic content, etc. Further, the methods of the invention may beimplemented in and with respect to different programming languages andwith and upon different platforms. The methods and systems of theinvention are applicable to security issues and problems that occur inthe context of modern computing systems, especially with respect tocomputers communicating over a communications network such as theInternet.

The examples above are simplified for the sake of illustration and donot showing testing of alphanumeric characters, e.g., A-Z and 0-9. Suchcharacters, like the special characters, may be tested according to theinvention. In addition, any type of characters or subset of charactersor combinations thereof may be tested according to the invention. Forexample, any or all of special characters, alphanumeric characters, andnon-printable characters may be tested for an application. Also, anycharacter set, such as ASCII or Unicode, or combinations thereof may betested.

Reference is made throughout this disclosure to browser-interpretable(or -executable) code such as HTML and scripting language such asJavaScript, and VBscript and internal data structures (referenced data)such as Document Object Model (DOM). It should be understood that theinvention is applicable to any type of browser-interpretable (or-executable) code, scripting language or internal data structure(referenced data) and that wherever in this application any of thesecategories or particular examples thereof is referenced, the inventionalso provides corresponding embodiments for the remaining categoriesgenerally and for the particular examples within those categories thatare disclosed herein.

Some portions of this description describe the embodiments of theinvention in terms of algorithms and symbolic representations ofoperations on information. These algorithmic descriptions andrepresentations are commonly used by those skilled in the dataprocessing arts to convey the substance of their work effectively toothers skilled in the art. These operations, while describedfunctionally, computationally, or logically, are understood to beimplemented by computer programs or equivalent electrical circuits,microcode, or the like. Furthermore, it has also proven convenient attimes, to refer to these arrangements of operations as modules, withoutloss of generality. The described operations and their associatedmodules may be embodied in software, firmware, hardware, or anycombinations thereof.

Any of the steps, operations, or processes described herein may beperformed or implemented with one or more hardware or software modules,alone or in combination with other devices. In one embodiment, asoftware module is implemented with a computer program product includinga computer-readable medium containing computer program code, which canbe executed by a computer processor for performing any or all of thesteps, operations, or processes described. As known in the art, variousdata structures such as databases, for example, relational databases maybe used to implement various aspects of the methods of the invention.

Embodiments of the invention may also relate to computerized systems forperforming the operations herein. Such apparatuses include a processor,processor accessible tangible memory and computer instructions (computerprogram) stored in the tangible processor accessible memory.Furthermore, any computing systems referred to in the specification mayinclude a single processor or may be architectures employing multipleprocessor designs for increased computing capability. It should also beunderstood that various of the operations and aspects of embodiments ofthe invention may be performed by distributed apparatuses.

The vulnerability detecting computer systems of the invention mayinterrogate subject systems/applications remotely via a communicationsconnection, for example, via a communications network such as theInternet. Thus, the computer systems of the invention may include acommunications network server/module that may, for example, includeand/or be physically connected to a communication network infrastructureby one or more electrical wires, such as twisted wires, e.g., twisted,copper wire(s) or coaxial cables such as copper or aluminum wire wrappedwith an insulating and flexible material, and/or by one or more opticalfibers such as by an optical fiber cable/bundle.

Although the foregoing description is directed to the preferredembodiments of the invention, it is noted that other variations andmodifications will be apparent to those skilled in the art, and may bemade without departing from the spirit or scope of the invention.Moreover, features described in connection with one embodiment of theinvention may be used in conjunction with other embodiments, even if notexplicitly stated above. In addition, methods including steps asdescribed herein may be performed in the step-wise order presented or inany operable order, all of which are intended to be within the scope ofthe invention.

The following computer program listing exemplifies computer codeconfigured to parse out the syntax (such as special characters)surrounding a returned default slug and determine which characters maybe added (in the space occupied by the returned default slug) in orderto build a syntactically correct piece of executable code, i.e., anexploit. By syntactically correct code, it is meant herein that thebrowser or similar subject application will be able to interpret theexploit and execute it, not that perfect HTML, JavaScript, etc. ispresent, since browsers and like applications through normal functionallow for deviations/errors in HTML/XML/JSON/etc. FIG. 6 shows anexemplary report showing the parsing and exploit generation resultsobtained by the program. Other computer code provided by the inventioncan be configured to direct the computer system of the invention togenerate and submit (attempt to load) test slugs to the targetapplication which consist of one or more test characters or strings,which may include the required character(s) or strings in encoded orun-encoded form, but can be any characters or strings, sandwichedbetween two default slugs (which may be the same or different) anddetermine if the application returns the test slug with the charactersrequired to form executable code, i.e., an exploit.

What is claimed is:
 1. A computer-implemented method for testing anapplication for cross-site scripting vulnerabilities, comprising thesteps of: under control of at least one processor, (a) for at least onefield, parameter or Uniform Resource Locator (URL) of the application,submitting a request in which the field, parameter or URL contains atest slug consisting of an encoded or non-encoded test character or astring of test characters between two default slugs; (b) determiningwhen the application returns the test slug with the test character orstring of test characters and whether any of the test characters in thetest slug are transformed or not transformed in the returned test slug;(c) storing in non-transitory computer memory the result of thedeterminations made in step (b); and (d) repeating steps (a)-(c) for aplurality of different test characters or strings of test characters. 2.The computer-implemented method of claim 1, wherein the test characteris a special character or at least one of the test characters of thestring of test characters is a special character.
 3. Thecomputer-implemented method of claim 1, further comprising the steps of:before steps (a)-(d), for at least one field, parameter or URL of theapplication, submitting a request in which the parameter, field or URLcontains a default slug not having any special characters; anddetermining when the application reflects the default slug without anytransformation of characters in response to the request, wherein whenthe application returns the default slug without any transformation ofcharacters, the test slug used in step (a) consists of the encoded ornon-encoded test character(s) sandwiched between two default slugs whichmay be the same or different.
 4. The computer-implemented method ofclaim 3, wherein the test character is a special character or at leastone of the test characters of the string of test characters is a specialcharacter.
 5. The computer-implemented method of claim 1, wherein instep (a), the at least one field, parameter or Uniform Resource Locator(URL) of the application comprises a URL.
 6. The computer-implementedmethod of claim 5, wherein the test character is a special character orat least one of the test characters of the string of test characters isa special character.
 7. The computer-implemented method of claim 3,wherein the submitting step performed before steps (a)-(d) comprises:before steps (a)-(d), for at least one URL of the application,submitting a request in which the URL contains a default slug not havingany special characters.
 8. The computer-implemented method of claim 7,wherein the test character is a special character or at least one of thetest characters of the string of test characters is a special character.9. A computer system configured to test an application for cross-sitescripting vulnerabilities, comprising: at least one processor;non-transitory processor-accessible memory; and computer instructionsstored in the non-transitory processor-accessible memory, said computerinstructions configured to direct the at least one processor to performthe steps of: (a) for at least one field, parameter or Uniform ResourceLocator (URL) of the application, submitting a request in which thefield, parameter or URL contains a test slug consisting of an encoded ornon-encoded test character or a string of test characters between twodefault slugs; (b) determining when the application returns the testslug with the test character or string of test characters and whetherany of the test characters in the test slug are transformed or nottransformed in the returned test slug; (c) storing in non-transitorycomputer memory the result of the determinations made in step (b); and(d) repeating steps (a)-(c) for a plurality of different test charactersor strings of test characters.
 10. The computer system of claim 9,wherein the test character is a special character or at least one of thetest characters of the string of test characters is a special character.11. The computer system of claim 9, further comprising: a communicationmodule under control of the at least processor, the communicationsmodule configured to provide communication between the computer systemand the application to be tested for cross-site scriptingvulnerabilities by the computer system.
 12. The computer system of claim11, wherein the test character is a special character or at least one ofthe test characters of the string of test characters is a specialcharacter.
 13. The computer system of claim 9, wherein the computerinstructions are further configured to direct the at least one processorto perform the steps of: before steps (a)-(d), for at least one field,parameter or URL of the application, submitting a request in which theparameter, field or URL contains a default slug not having any specialcharacters; and determining when the application reflects the defaultslug without any transformation of characters in response to therequest, wherein when the application returns the default slug withoutany transformation of characters, the test slug used in step (a)consists of the encoded or non-encoded test character(s) sandwichedbetween two default slugs which may be the same or different.
 14. Thecomputer system of claim 10, wherein the computer instructions arefurther configured to direct the at least one processor to perform thesteps of: before steps (a)-(d), for at least one field, parameter or URLof the application, submitting a request in which the parameter, fieldor URL contains a default slug not having any special characters; anddetermining when the application reflects the default slug without anytransformation of characters in response to the request, wherein whenthe application returns the default slug without any transformation ofcharacters, the test slug used in step (a) consists of the encoded ornon-encoded test character(s) sandwiched between two default slugs whichmay be the same or different.
 15. The computer system of claim 11,wherein the computer instructions are further configured to direct theat least one processor to perform the steps of: before steps (a)-(d),for at least one field, parameter or URL of the application, submittinga request in which the parameter, field or URL contains a default slugnot having any special characters; and determining when the applicationreflects the default slug without any transformation of characters inresponse to the request, wherein when the application returns thedefault slug without any transformation of characters, the test slugused in step (a) consists of the encoded or non-encoded testcharacter(s) sandwiched between two default slugs which may be the sameor different.
 16. The computer system of claim 12, wherein the computerinstructions are further configured to direct the at least one processorto perform the steps of: before steps (a)-(d), for at least one field,parameter or URL of the application, submitting a request in which theparameter, field or URL contains a default slug not having any specialcharacters; and determining when the application reflects the defaultslug without any transformation of characters in response to therequest, wherein when the application returns the default slug withoutany transformation of characters, the test slug used in step (a)consists of the encoded or non-encoded test character(s) sandwichedbetween two default slugs which may be the same or different.